This was discussed on the 9-Oct-24 Federation editors' call. We'd like to get @rohe's view on this proposal.

I can't see that this allows us to do something that we can't do today.
On the other hand it adds complexity to the code.

@zachmann can you please respond to @rohe's assessment of the situation? Thanks.

We discussed this on the 23-Oct-24 Federation editors' call. We plan to close this in a week if no response is received.

Sorry for the delayed response, I've fallen sick after my vacation.

In my opinion this does not (necessarily) add complexity to the code. The value operator sets the value, after that the other operators are applied according to their rules. I only intended to allow combining them, there is no special handling needed.

The benefit of this would be to allow authorities to set policy checks while one authority sets a value. As I see it, currently value is more or less unusable in a slightly complex federation, as soon as some one else also wants to define a policy on this parameter (unless it's coincidentally the same rule).
But I don't see the reason to fail if authority A says value: ES512 and authority B one_of: [ES256, ES512]

Is authority A higher up (closer to the TA) in the trust chain compared to B ?

Does it matter? I think according to 6.1.1 Equal Opportunity it should not matter, if A or B is higher up.

What we have right now in the specification is the rule that an intermediate can not specify a policy that is less restrictive than the combined policy for its superiors in the trust chain.
What you @zachmann want, seems to be that the check for "less restrictive" should be done after the subordinates policy has been applied.
That is, is the resulting policy after the application of the subordinates policy "less restrictive" than if it was not applied? If so the subordinates policy according to you should be allowed.
Correct ?

This is quite a change in my mind.

What we have right now in the specification is the rule that an intermediate can not specify a policy that is less restrictive than the combined policy for its superiors in the trust chain.

That's surprising for me (or might have misunderstood your comment). I always assumed it would not matter; it also does not seem logical for me. It should not be expected from an entity to know the superior policies. I always assumed the idea was that each federation entity can have their own independent policies.

If the superior policy would be one_of: [ES256, ES512] and the subordinate specifies one_of: [ES256, ES512, RS256], this should work without problems, even thought it's more permissive. Those will just be merged by the rules in the spec (intersection) and the result will be one_of: [ES256, ES512].

Of course the policy of an intermediate cannot result in something more permissive. If that would be the case it cannot be merged; but the policy itself can be more permissive, and will be adjusted in the merging process.

However, in this case I'm talking about the combination of different policy operators. Still I dont see why we should forbid this:
authority A says value: ES512 and authority B one_of: [ES256, ES512], nevertheless if A is on top of B or the other way round.

I did a first pass over the PR, without analysing the individual combinations yet.

At present, every policy operator is specced according to a template, with the allowed combinations going into the "Combination with other operators in a metadata parameter policy:" sections.

The current operator combination rules primarily define which operators may be put together for a given metadata parameter, within the policy of a single entity. Which rules, by extension, also hold for the case when the operators are found in statements along the trust chain.

Policy architects are likely to read the current combination rules (and the proposed PR changes) as a description of which operators may be put together in a single policy statement. This PR however is primarily intended to spec combinations that may appear when policy statements in a trust chain get merged.

To illustrate, the PR combination of value and default doesn't make much sense within a single policy statement.

Yes, that's right this PR is targeted only for the combinations that may appear when policy statements are merged; not for within a single entity statement.

I also wondered how it is currently intended and if it makes sense to differentiate between those cases. (Or if the merging case shouldn't be explicitly considered, and a simple note about it would be enough.)

@vdzhuvinov, would it make sense for you to add a sentence or two to the draft explaining the above intent about operator combinations?

@vdzhuvinov, would it make sense for you to add a sentence or two to the draft explaining the above intent about operator combinations?

I created a separate ticket for this, because it's related to the section that describes the general working of the metadata policies:

#129